A Study of the Impact of Requirements Volatility on Software Project Performance

Software development is considered to be a dynamic process where demands for changes seem to be inevitable. Modifications to software are prompted by all kinds of changes including changes to the requirements. This type of changes gives rise to an intrinsic volatility, which has several impacts on the software development lifecycle. This paper describes our findings of an extensive survey based empirical study of requirement volatility (RV) and its impact on software project performance. In particular, findings reveal that requirement volatility has a significant impact on schedule overrun and cost overrun in software projects. Our investigation also examined factors that contribute to the extent of requirement volatility and found that variables such as frequent communications between users and developers and usage of a definable methodology in requirements analysis and modeling have impact on the stability of requirements

Managing conflicts among non-functional requirements

Abstractâ Non-functional requirements (NFRs) tend to interfere, conflict, and contradict with one other. Unlike functional requirements, this inevitable conflict arises as a result of inherent contradiction among various types of NFRs. A number of techniques to deal with this conflict have been developed. Majority of them focus on categorizing, documenting, or listing the potential conflicts among NFRs. Several models that represent the positive or negative relationships among NFRs have also been published in literature. However, the interpretation of NFRs may vary depending on numerous factors, such as the context of the system being developed and stakeholder involvement. Consequently, the relationships among them are not always obvious. This paper investigates the gaps in the existing research literature about the conflicts among NFRs and proposes a framework to manage this type of conflict

Using card sorting technique to classify requirements change

Requirements Volatility is considered to be a major source of risk to the management of large and complex software projects. The ability to characterise the nature and origins of requirements change during software development is important and can lead organisations towards more effective management of changing requirements. This paper focuses on a study to establish how practitioners classify requirements change requests. We used the Card Sorting method to identify categories of change requests that software developers use in practice. Card sorting is a knowledge elicitation method that is commonly used for capturing information about different ways of representing domain knowledge. This study has allowed us to get valuable insights into the way practitioners classify change requests and to understand their perspectives on classification. This classification is a valuable source of information in prioritizing change requests and assessing their impact. Our findings from the card sorting exercise further reveal that the criteria used for categorization are related to the role the practitioner plays in the software development team and the nature and extent of their responsibilities. © 2004 IEEE

Analysis of requirements volatility during software development life cycle

Investigating the factors that drive requirements change is an important prerequisite for understanding the nature of requirements volatility. This increased understanding will improve the process of requirements change management. This paper mainly focuses on change analysis to identify and characterize the causes of requirements volatility. We apply a causal analysis method on change request data to develop a taxonomy of change. This taxonomy allows us to identify and trace the problems, reasons and sources of changes. Adopting an industrial case study approach, our findings reveal that the main causes of requirements volatility were changes in customer needs (or market demands), developers' increased understanding of the products, and changes in the organization policy. During the development process, we also examined the extent of requirements volatility and discovered that the rate of volatility was high at the time of requirements specification completion and while functional specification reviews were conducted

An investigation into the notion of non-functional requirements

Although Non-Functional Requirements (NFRs) are recognized as very important contributors to the success of software projects, studies to date indicate that there is still no general consensus in the software engineering community regarding the notion of NFRs. This paper presents the result of an extensive and systematic analysis of the extant literature over three NFRs dimensions: (1) definition and terminology; (2) types; and (3) relevant NFRs in various types of systems and application domains. Two different perspectives to consider NFRs are described. A comprehensive catalogue of NFRs types as well as the top five NFRs that are frequently considered are presented. This paper also offers a novel classification of NFRs based on types of systems and application domains. This classification could assist software developers in identifying which NFRs are important in a particular application domain and for specific systems. © 2010 ACM

Requirements change: What's the alternative?

Numerous studies have shown that a software project's cost, schedule and defect density escalate as the rate of requirements change increases. Yet none of these studies have explored the effects of not making requirements changes in response to changes in user needs. This paper explains why a project incurs just as much, if not more, risk when requirements changes are suppressed. © 2008 IEEE

Towards a catalogue of conflicts among non-functional requirements

Two of the most significant characteristics of non-functional requirements (NFRs) are "interacting" and "relative". Interacting means NFRs tend to interfere, conflict, and contradict with one other while relative means the interpretation of NFRs may vary depending on many factors, such as the context of the system being developed and the extent of stakeholder involvement. For the purpose of understanding the interacting characteristic of NFRs, several potential conflict models have been presented in the literature. These models represent the positive or negative inter-relationships among various types of NFRs. However, none of them deal with the relative characteristic of NFRs. In fact, multiple interpretations of NFRs in the system being developed may lead to positive or negative inter-relationships that are not always obvious. As a result, the existing potential conflict models remain in disagreement with one other. This paper presents the result of an extensive and systematic investigation of the extant literature over the notion of NFRs and conflicts among them. A catalogue of NFRs conflicts with respect to the NFRs relative characteristic is presented. The relativity of conflicts is characterized by three categories: absolute conflict; relative conflict; and never conflict. This catalogue could assist software developers in identifying the conflicts among NFRs, performing further conflict analysis, and identifying the potential strategies to resolve those conflicts

Requirements fixation

There is a broad consensus that understanding system desiderata (requirements) and design creativity are both important for software engineering success. However, little research has addressed the relationship between design creativity and the way requirements are framed or presented. This paper therefore aims to investigate the possibility that the way desiderata are framed or presented can affect design creativity. Forty two participants took part in a randomized control trial where one group received desiderata framed as “requirements” while the other received desiderata framed as “ideas”. Participants produced design concepts which were judged for originality. Participants who received requirements framing produced significantly less original designs than participants who received ideas framing (Mann-Whitney U=116.5, p=0.004). We conclude that framing desiderata as “requirements” may cause requirements fixation where designers’ preoccupation with satisfying explicit requirements inhibits their creativity

Challenges in aligning requirements engineering and verification in a large-scale industrial context

[Context and motivation] When developing software, coordination between different organizational units is essential in order to develop a good quality product, on time and within budget. Particularly, the synchronization between requirements and verification processes is crucial in order to assure that the developed software product satisfies customer requirements. [Question/problem] Our research question is: what are the current challenges in aligning the requirements and verification processes? [Principal ideas/results] We conducted an interview study at a large software development company. This paper presents preliminary findings of these interviews that identify key challenges in aligning requirements and verification processes. [Contribution] The result of this study includes a range of challenges faced by the studied organization grouped into the categories: organization and processes, people, tools, requirements process, testing process, change management, traceability, and measurement. The findings of this study can be used by practitioners as a basis for investigating alignment in their organizations, and by scientists in developing approaches for more efficient and effective management of the alignment between requirements and verification